Intuitivitely it should be faster. Do you have some measurement?

I don't think such micro optimisations will make any big difference. I think the focus should be rewriting algorithms to make it faster.

I attached links to benchmarks. There's no way to make the algorithm faster. It's a suboptimal implementation in the standard,

In the matchcompiler we optimize s == "1" to s.size() == 1U && s[0] == '1'. So we jump through bigger hoops in other code to get slight performance improvements. This is quite similar and in this case the code stays virtually identical.

This is quite similar and in this case the code stays virtually identical.

We get more and more micro optimisations... it's not good and it gets worse and worse.

I don't want to unroll all the micro optimisations we made at this point. But if we can stop making more it would make me feel better.

I am not strongly against this particular PR we can reluctantly merge this now. I don't feel there is any payoff. I wonder how I can stop the focus on micro optimisations. I would assume that we can rewrite parser code and get significant speedups.

Well the speed-up is above a micro optimization if it delivers a performance of 1.8. The linked benchmark is measuring actual time and not instruction count. Which is what we actually should be profiling for. This is just an easy "win" compared with the other stuff I did. And we have tooling to support use with.

Just "rewriting" parsers and other things will lead to actual micro-optimizations like hot and cold attributes, refactoring to avoid cache misses and other things which make the code harder to read. That might also vary with the compiler you are using. But all those speed-ups would not help much as there's still the ValueFlow...

I am already trying to find ways to get rid of the matchcompiler and have the compilers behave better with common patterns.

Well the speed-up is above a micro optimization if it delivers a performance of 1.8.

Ok thanks I did not see that benchmark. However I assume the difference in Cppcheck analysis time will be very small.

Maybe micro optimisations are more OK in the matchcompiler output. If there is something we can safely do. Whatever it means to readability does not matter then.

The linked benchmark is measuring actual time and not instruction count. Which is what we actually should be profiling for.

I agree

Just "rewriting" parsers and other things will lead to actual micro-optimizations

In my opinion you are not talking about "rewriting" then. I am not talking about rearranging code to avoid cache misses.

But all those speed-ups would not help much as there's still the ValueFlow...

I agree. We need to be much more careful in the ValueFlow.

The linked benchmark is measuring actual time and not instruction count. Which is what we actually should be profiling for.

I agree

I am learning and improving my approaches as well as refining my Cppcheck and LLVM tickets.

Just "rewriting" parsers and other things will lead to actual micro-optimizations

In my opinion you are not talking about "rewriting" then. I am not talking about rearranging code to avoid cache misses.

I took a short look at cache misses and we have buckets of them. They primarily seem to be related to lambda usage but I couldn't really figure out where exactly. I am just not familiar with cache profiling. But it might also be some shortcomings because we cannot move variables into lambdas yet.

Maybe micro optimisations are more OK in the matchcompiler output. If there is something we can safely do. Whatever it means to readability does not matter then.

I would really love if the compiler would just generate optimal code for std::string usage and we could drop (most of) that. It's not like that is some kind of corner case...

I will do some before and after profiling of these changes still.

Good news. perf appears to be working in WSL2 now so it should now be possible to do actual profiling based on cycles instead of instructions. That value is obviously not as stable as the instruction count. But it also includes the actual used time.